Method and system for generating account reconciliation data

ABSTRACT

A method and system for providing information regarding a customer account are provided. The customer account includes a plurality of entries, each entry being indicative of a request for payment where the request for payment is being issued by a biller entity to a customer entity. A payment record including remittance detail data is received over a network account reconciliation data at least in part on the basis of the remittance detail data and the entries in the customer account. A signal suitable for causing information derived from the account reconciliation data to be displayed on a display screen is then transmitted.

FIELD OF THE INVENTION

[0001] This invention relates to a system and method for facilitatingonline commerce over a public network such as the Internet or aninteractive T.V. cable network. More particularly, this inventionrelates to a system and method for conducting online processing of aninvoice including the generation of account reconciliation data.

BACKGROUND OF THE INVENTION

[0002] Online commerce has experienced dramatic growth in recent yearsand this growth is expected to continue into the coming decades.Internet service providers are, more and more, connecting users to theInternet at no cost, thus eliminating barriers to an Internetconnection. At the same time, merchants are increasingly developingsites on the World Wide Web (or simply “WWW” or “Web”) that customerscan access to order goods and/or services. It is now fairly common for acustomer to browse a merchant's catalogue, select a product or serviceand place an order for the product/service, all electronically over theInternet. Similarly, it is becoming increasingly common for merchants toallow payment of invoices electronically. Typically, the invoice is sentelectronically to the customer via electronic mail or made available tothe customer over a network by providing the customer with networkaccess capability.

[0003] U.S. Pat. No. 6,128,603 issued to Dent et al. on Oct. 3, 2000describes a consumer-based system for analyzing, managing and payingelectronic bill statements received from a biller. The billerelectronically transmits a customized statement to a consumer's computerterminal over the Internet. The biller's electronic bill is presented tothe consumer through a user interface. After reviewing the electronicbill the consumer can enter how much of the bill to pay, from whichaccount to pay from, and the desired payment date. The enteredinformation is then transmitted to the biller for processing. Thecontents of U.S. Pat. No. 6,128,603 are incorporated herein byreference.

[0004] Similarly, U.S. Pat. No. 6,070,150, issued to Remington et al. onMay 30, 2000, describes an electronic payment system in which a billerelectronically transmits a bill to a consumer over the Internet. Thebill may arrive at the consumer's terminal via email or a through anotification for the consumer to check a billing mailbox. The consumerreceives the bill that can be displayed in the form of a user interface.After reviewing the bill the consumer is able to enter the amount to bepaid, the date of payment and from which account the money can be taken.The system described in Remington et al. also includes the ability tolet the consumer dispute an item in an invoice. The contents of U.S.Pat. No. 6,070,150 are incorporated herein by reference.

[0005] A deficiency with the above-described systems for the electronicpayment of invoices is that they are ill suited to certainbusiness-to-business environments. In a typical business settinginvolving merchant entities manipulating large numbers of invoices, whena customer pays an invoice to a merchant entity, a check is written andsent to a post office box and directed to a lock box site. A check canbe used to pay one or more invoices and is typically accompanied byremittance details to allow matching the check to one or more invoicesissued by the merchant entity. The bank manages the checks received atthe lock box site and keys in the remittance details into an electronicformat that is forwarded to the merchant entity for further processing.The merchant entity applies the remittance details received from thebank to the accounts receivable to reconcile the customer account. Forthe keying of the remittance details into an electronic format, the bankcharges the merchant entity a fee for the processing of each check. Thefees can be significant without accounting for the delays in processingof the bank.

[0006] Consequently there exists a need in the industry to provide animproved system and method for providing remittance details andgenerating account reconciliation data regarding a customer account thatalleviates at least in part the deficiencies of prior art systems andmethods.

SUMMARY

[0007] In accordance with a broad aspect, the invention provides amethod for providing information regarding a customer account. Thecustomer account includes a plurality of entries, each entry beingindicative of a request for payment. A payment record is received over anetwork from a user associated to the customer account. The paymentrecord includes remittance detail data. Account reconciliation data isgenerated at least in part on the basis of the remittance detail dataand the entries in the customer account. A signal is then transmittedover a network, the signal suitable for causing information derived fromthe account reconciliation data to be displayed on a display screen.

[0008] Advantageously, the invention allows a user associated with acustomer entity to transmit proprietary electronic remittance detailfiles including remittance detail data to the biller system by uploadingthe remittance detail files over a network. The uploaded remittancedetail file is then used by the biller system to generate reconciliationdata for the customer account.

[0009] Another advantage of the present invention is that it allows auser and a biller entity to have access to the same payment records incontrast to payment records provided by a third party such as a bank.This allows discrepancies in the payment record information to beidentified and corrected more readily since the user and the billerentity are looking at the same information.

[0010] Advantageously, the present invention allows a reduction in therequirement for a third party, such as a bank or value added network, toprovide payment detail information. This results in a saving of timein-house for the biller in terms of clerical time.

[0011] In a specific implementation, the information derived from theaccount reconciliation data includes a confirmation message indicatingthat the payment record has been processed. In another specificimplementation, the information derived from the account reconciliationdata includes data indicative of reconciliation events.

[0012] Advantageously, the invention allows providing informationderived from the account reconciliation data to the user therebyallowing discrepancies between the amounts appearing on the paymentrecord and the requests for payment to be identified early on in thepayment process.

[0013] In a specific implementation, the account reconciliation dataincludes a request identifier associated to the corresponding requestfor payment and an amount data element.

[0014] In a specific implementation, the payment record is associated toa corresponding request for payment in the customer account at least inpart on the basis of a level of match between the remittance detail dataand the corresponding request for payment in the customer account. Theaccount reconciliation data is generated at least in part on the basisof the remittance detail data and the corresponding request for payment.

[0015] In a non-limiting implementation, the level of match isindicative of either one of a complete match, a match with variances oran unreconciled item. The account reconciliation data may furtherinclude data indicative of differences between the remittance detaildata and the corresponding request for payment when the level of matchis indicative of a match with variances. A user associated to thecustomer entity is enabled to provide explanation data in associationwith the account reconciliation data.

[0016] In a specific example of implementation, each entry in thecustomer account includes a plurality of payment request parameters. Theremittance detail data is compared to the payment request parameters toderive a level of match between the given payment record and an entry inthe customer account.

[0017] In accordance with another broad aspect, the invention provides acomputer readable medium including a program element suitable forexecution by a computing apparatus for providing information regarding acustomer account in accordance with the above described method.

[0018] In accordance with another broad aspect, the invention provides amethod for providing information regarding a customer account. Thecustomer account includes a plurality of entries, each entry beingindicative of a request for payment. The method includes enabling a userat a computer terminal to transmit data indicative of a payment recordincluding remittance detail data associated to the customer account.Information data is caused to be displayed at the computer terminal, theinformation data being indicative of account reconciliation data derivedat least in part on the basis of the remittance detail data and theentries in the customer account.

[0019] In a specific implementation, the account reconciliation dataincludes a request identifier associated to the corresponding requestfor payment and an amount data element. Optionally, the accountreconciliation data further includes a data element indicative of alevel of match between the remittance detail data and the entries in thecustomer account. In a non-limiting implementation, the level of matchis indicative of either one of a complete match, a match with variancesor an unreconciled item. In a non-limiting implementation, the accountreconciliation data includes data indicative of differences between theremittance detail data and the corresponding request for payment whenthe level of match is indicative of a match with variances. As avariant, a user at the computer terminal is enabled to provideexplanation data in association with the account reconciliation data.

[0020] In accordance with another broad aspect, the invention provides acomputer readable medium including a program element suitable forexecution by a computing apparatus for providing information regarding acustomer account in accordance with the above described method.

[0021] In accordance with another broad as aspect, the inventionprovides a computer readable storage medium storing a program elementfor execution by a CPU for providing information regarding a customeraccount. The customer account includes a plurality of entries, eachentry being indicative of a request for payment, the request for paymentbeing issued by a biller entity to a customer entity. The programelement includes a first program element component for causing acomputer to deliver first information to a user. The first informationprompts the user to provide a payment record including remittance detaildata. The program element also includes a second program elementcomponent responsive to the payment record for generating accountreconciliation data at least in part on the basis of the remittancedetail data and the entries in the customer account. The program elementalso includes a third program element for transmitting over a network asignal, the signal being suitable for causing second information derivedfrom the account reconciliation data to be displayed on a displayscreen.

[0022] In a non-limiting implementation, the first information isdelivered to the user by displaying information on a screen. The userprovides the payment record through an input device selected in thegroup consisting of keyboard, pointing device, touch sensitive surface,speech recognition unit and a file.

[0023] In a first specific non-limiting implementation, the CPU resideson a server machine and the computer is a client machine in a networkarrangement with the server machine. The first program element componentgenerates control messages to the client machine to cause the clientmachine to display information to the user. For example, the controlmessages may be HTTP messages and the client machine displaysinformation to the user through a web browser. Other suitable messageformats and displays may be used without detracting from the spirit ofthe invention.

[0024] In a second specific non-limiting implementation, the CPU residesin the computer.

[0025] In accordance with another broad aspect, the invention provides aserver system for providing information regarding a customer account.The customer account includes a plurality of entries, each entry beingindicative of a request for payment, the request for payment beingissued by a biller entity to a customer entity. The server system storesa program element for execution by a CPU including a first programelement component for causing a client system connected to the servervia a network to display first information to a user. The firstinformation prompts the user to provide a payment record includingremittance detail data. The program element also includes a secondprogram element component responsive to the payment record forgenerating account reconciliation data at least in part on the basis ofthe remittance detail data and the entries in the customer account. Theprogram element also includes a third program element component fortransmitting a signal to the client system over a network, the signalbeing suitable for causing information derived from the accountreconciliation data to be displayed on a display screen at the clientsystem.

[0026] In accordance with yet another broad aspect, the inventionprovides a client-server system for providing information regarding acustomer account. The customer account includes a plurality of entries,each entry being indicative of a request for payment, the request forpayment being issued by a biller entity to a customer entity. Theclient-server system includes a client system and a server systemoperative to exchange messages over a data network. A first programelement component executed on the server system is for sending messagesto the client system for causing the client system to display firstinformation to a user. The first information prompts the user to providea payment record including remittance detail data. The client system isoperative to send messages to the server to communicate to the serverthe payment record including remittance detail data. A second programelement component executed on the server is responsive to the paymentrecord for generating account reconciliation data at least in part onthe basis of the remittance detail data and the entries in the customeraccount. A third program element component executed on the server is fora second program element component for transmitting to the client systemover a network a signal. The signal is suitable for causing informationderived from the account reconciliation data to be displayed on adisplay screen at the client system.

[0027] Other aspects and features of the present invention will becomeapparent to those ordinarily skilled in the art upon review of thefollowing description of specific embodiments of the invention inconjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0028]FIG. 1 is a block diagram of a system suitable for providinginformation regarding a customer account in accordance with anembodiment of the invention, including a biller computing system 116, anetwork 106, and a customer computing system 150;

[0029]FIG. 2a is a block diagram depicting a customer computing unit inthe customer computing system 150 shown in FIG. 1 in accordance with anembodiment of the invention;

[0030]FIG. 2b is a block diagram depicting the biller computing system116 shown in FIG. 1 in accordance with an embodiment of the invention;

[0031]FIG. 3 is a simplified flow diagram of a process for generatingaccount reconciliation data for a user account in accordance with aspecific example of implementation of the invention;

[0032]FIG. 4 is a flow diagram depicting in greater detail the processshown in FIG. 3 for generating account reconciliation data in accordancewith a specific non-limiting example of implementation of the invention;

[0033]FIG. 5 is a non-limiting example of implementation of a graphicaluser interface for allowing a user associated with a customer entity totransmit to a biller entity a remittance detail file including paymentrecords in accordance with a specific non-limiting example ofimplementation of the invention;

[0034]FIG. 6 is a non-limiting example of implementation of a graphicaluser interface for displaying a transaction confirmation messageincluding account reconciliation data in accordance with a specificnon-limiting example of implementation of the invention.

[0035] In the drawings, embodiments of the invention are illustrated byway of example. It is to be expressly understood that the descriptionand drawings are only for purposes of illustration and as an aid tounderstanding, and are not intended to be a definition of the limits ofthe invention.

DETAILED DESCRIPTION

[0036]FIG. 1 shows a system 100 for providing account reconciliationdata in accordance with a specific implementation. The system 100 allowsa customer entity 102 to provide payment records including remittancedetail data to a specific biller entity 104 such as to allow the billerentity 104 to generate account reconciliation data on the basis of thepayment records provided by the customer. The system 100 includes abiller computing system 116 and a customer computing system 150interconnected through a network 106. The biller computing system 116and the customer computing system 150 include tools for facilitatingonline commerce transactions between the customer entity 102 and thebiller entity 104.

[0037] The network 106 is a data communication network interconnectingthe customer computing system 150 and the biller computing system 116.In a specific example of implementation, the network 106 is a publicnetwork. In the illustrated implementation, the data communicationnetwork 106 is embodied in the Internet. It is to be noted that the datacommunication network 106 may be implemented as a network other that theInternet such as an interactive television (ITV) network, a privatenetwork such as an Intranet or any other suitable network.

[0038] Customer Computing System 150

[0039] The customer computing system 150 comprises one or more computingunits 112, each associated to a respective user 108. The computing unit112 is generally in the form of a personal computer, although othertypes of computing units may be used including laptops, notebooks,hand-held computers, set top boxes, and the likes. The computing unit112 may be connected to other computing units over an Intranet or may bea stand-alone computing unit. The computing unit 112 is provided with aconnection to the network 106. The connection may be a permanentconnection through a server at the customer's premises, oralternatively, a given computing unit may occasionally connect to thenetwork 106 through the use of a dial-up connection using suitabledevices, such as a modem for example. For the purpose of simplicity, theexamples described herein below consider a customer computing system 150including a single customer computing unit 112 associated to a firstuser 108. It will be readily appreciated that a customer computingsystem 150 including in excess of a single customer-computing unitremains within the invention.

[0040]FIG. 2a depicts a block diagram of customer computing unit 112. Asshown, the customer computing unit 112 comprises a processor 210, amemory 220 and a network I/O 224 (input/output) for accessing thenetwork 106. The network I/O 224 can be implemented, for example, as adial-up modem or as a permanent network connection. The processor 210 isadapted to execute program elements stored in the memory 220 forperforming certain functions. More specifically, the customer computingunit 112 runs an operating system 218 that supports multipleapplications. The operating system 218 is preferably a multitaskingoperating system that allows simultaneous execution of multipleapplications in a graphical windowing environment. The memory 220 alsoincludes a browser program element 222. The browser program element 222when launched is executed by the processor 210 atop the operating system218. The customer computer unit 112 may also include e-mail softwarecomponents (not shown) as well as additional components and modules.These have been omitted from the description for the purpose of clarity.

[0041] The memory 220 also includes a data portion 260 suitable forstoring remittance detail files. In the specific example ofimplementation, the memory 220 includes one or more remittance detailfiles for storing one or more payment records. Such remittance detailfiles may be in any suitable format allowing information containedtherein to be extracted therefrom. The accounts payable department ofbusinesses commonly generates such remittance detail files in order tokeep records of what invoices were paid to insure that the checksbalance. In a specific implementation, each payment record includesremittance detail data. The remittance detail data describes what thecustomer is paying. Optionally, each payment record includes a paymentvehicle identifier indicative of the medium through which the paymentwill take place. The vehicle identifier may be indicative of a checknumber, a bank draft number, a wire transfer number or any othersuitable identifier for identifying a medium for transferring funds.

[0042] The remittance detail data may include a request identifier, adollar amount paid, a time data element, a service description dataelement and a product description data element amongst others. The typesof remittance detail data items in each payment record may vary from onepayment record to the other without detracting from the spirit of theinvention. Consider the following three payment records as non-limitingexamples:

[0043] a) a first payment record includes remittance detail dataindicative of a dollar amount paid and a request identifier in the formof an invoice number;

[0044] b) a second payment record includes remittance detail dataindicative of a request identifier;

[0045] c) a third payment record includes a remittance detail dataindicative of a time data element indicative of a shipment date and adollar amount.

[0046] The remittance detail files including payment records are storedin any suitable file format. Non-limiting examples of file formatsinclude text files, spreadsheet files, .pdf files as well as image fileformats. It will be appreciated that where image file formats are used,suitable optical character recognition software will be used to extractthe information therefrom.

[0047] In a first specific example of implementation, a remittancedetail file storing payment records includes a data structure in theform of a table where each row is associated to a respective paymentrecord. Table 1 below shown a non-limiting example of a data structurefor storing payment records: TABLE 1 Request identifier Amount paidS97468 5000$ S97478 2600$ S97374 1000$ S97946 8000$ S94683 2000$ S946882000$ 1500$

[0048] As shown above, certain records may have missing information suchas a missing request identifier or a missing dollar amount paid.

[0049] In a second specific example of implementation, each remittancedetail file storing payment records is associated to a respectivepayment vehicle identifier. Table 2 below shows a non-limiting exampleof a data structure including payment records: TABLE 2 Requestidentifier Amount paid Product description Check No. S97468 5000$Portable remote control 1234567890 unit S97478 2600$ Leather couch1234567890 S97374 1000$ 32” television 3743558 S97946 8000$ Surroundsound system 38551 S94683 2000$ Computer 867846 S94688 2000$ Trip toParis 24532 1500$ Stove 23455

[0050] It is to be understood that the above data structures are shownfor the purpose of illustration only and that other suitable datastructures are possible without detracting from the spirit of theinvention.

[0051] Biller Computing System 116

[0052] The biller computing system 116 includes one or more computerservers and one or more computing apparatuses. The system includesprogram elements allowing the biller entity 104 to manage customerinvoices and to provide electronic processing of invoices. The billercomputing system 116 may also include modules for connection to apayment network 152 (shown in FIG. 1). The payment network 152represents existing networks that presently accommodate transactions forcredit cards, debit cards, direct debits, checks and other types offinancial payment processes. The biller computing system 116 receivesfrom the payment network 152 data elements associated to respectivecustomers and indicative of an amount paid. For example, for each checkreceived at the lock box site, a record is generated indicative of theamount paid by a given customer. This record is then sent to the billercomputing system 116. A description of the payment network 152 and ofthe interaction of the biller computing system 116 with the paymentnetwork 152 is not necessary for the understanding of the presentinvention and as such will not be described.

[0053]FIG. 2b shows a block diagram depicting a schematic diagram of thebiller computing system 116. As depicted, the biller computing system116 comprises a processor 208, a memory 200 and a network I/O 226(input/output) for connection to the network 106. The network I/O 226 ispreferably implemented as a permanent network connection although dialup connections may be suitable in certain embodiments. For example, ifthe biller computing system 116 interacts with the customer computingsystem 150 via e-mail, then a dial-up connection may be suitable.

[0054] The processor 208 is adapted to execute program elements 204stored in the memory 200 for performing various functions. The memory200 also has a data portion 206 including a customer database 202, aninvoice database 203, a database for storing customer payment records207 and account reconciliation data 262. It will be readily appreciatedthat the biller computing system 116 may include additional componentsand modules. These have been omitted from the description for thepurpose of clarity.

[0055] The customer database 202 includes information pertaining to thecustomers of the biller entity. In a non-limiting implementation, foreach customer entity, an entry is provided including various informationdata elements associated to the customer entity. Amongst others, eachentry includes a user identifier with a corresponding password. The useridentifiers are provided by the customer entity 102 to the biller 104via a registration process. The biller computing system 116 stores atthe biller entity 104 a customer account in the customer database 202associated to each respective customer.

[0056] The invoice database 203 includes for each customer in thecustomer database 202 a list of payment requests associated to invoicesthat are not fully paid. Each payment request includes a plurality ofpayment request parameters including, for example, a payment requestidentifier, dollar amount due, a time data element, a servicedescription data element and a product description data element. Otherdata elements may be added and certain items may be omitted withoutdetracting from the spirit of the invention. The table below shows anon-limiting example of a list of payment requests. TABLE 3 PaymentRequests for Customer ABC INC. Payment request identifier (invoicenumber) Amount due Product description S97468 5000$ Portable remotecontrol unit S97478 2700$ Leather couch S97374 1000$ 32” televisionS97946 8000$ Surround sound system S94683 10000$ Dining room set S946882200$ Trip to Cuba S94693 1500$ Stove

[0057] The database for storing customer payment records 207 stores acopy of remittance detail files received from the customer entity 150.In other words, the remittance detail files originally provided by acustomer are preferably maintained at the biller site. Advantageously,this allows a user at the biller site to have access to the same data asthe customer, which is particularly practical in the case of billingdisputes since both parties have access to the same information. Thetable below shows a non-limiting example of a list of payment records.TABLE 4 Payment Records for Customer ABC INC. Request identifier Amountpaid Product description S97468 5000$ Portable remote control unitS97478 2600$ Leather couch S97374 1000$ 32” television S97946 8000$Surround sound system S94683 2000$ Computer S94688 2000$ Trip to Paris1500$ Stove

[0058] The database for storing account reconciliation data 262 storesthe results of the reconciliation process between the remittance detailsin the remittance detail file sent by the customer and the entries inthe invoice database 203. The invoice database 203 includes a pluralityof entries, each entry being associated to a reconciliation event in thedatabase for storing account reconciliation data 262. In a specificexample, each entry includes a request identifier and an amount. Inaccordance with a variant, each entry further includes a data elementindicative of the level of match between a given request for payment inthe invoice database and a payment record. The level of match may beindicative of either one of a complete match, a match with variances oran unreconciled item. In accordance with non-limiting implementation,when the level of match is indicative of a match with variances, thereconciliation event includes account reconciliation data indicative ofdifferences between the remittance detail data and the correspondingrequest for payment. In accordance with another non-limitingimplementation, when the level of match is indicative of a match withvariances, the reconciliation event includes customer explanation datadescribing the reason for differences between the remittance detail dataand the corresponding request for payment.

[0059] Optionally, each entry further includes a payment vehicleidentifier. The payment vehicle identifier may be indicative of a checknumber, a bank draft number, a wire transfer number or any othersuitable identifier for identifying a medium for transferring funds.

[0060] The table 5 below shows a specific non-limiting example of atable including entries associated to respective reconciliation eventson the basis of the entries shown in tables 3 and 4 above. TABLE 5Account Reconciliation Data for Customer ABC INC. Payment request AmountLevel identifier due Amount paid of match Differences S97468 5000$ 5000$Complete S97478 2700$ 2600$ match with Amount due ≠ amount variancespaid S97374 1000$ 1000$ Complete S97946 8000$ 8000$ Complete S9468310000$ 2000$ Unreconciled Amounts and product description do not match.S94688 2200$ 2000$ match with No match for product variances descriptionAmount due ≠ amount paid S94693 1500$ 1500$ Complete

[0061] In a specific implementation, a customer account entry in thecustomer database 202 includes links to an entry in the invoice database203, an entry in the account reconciliation database 262 and an entry inthe database of payment records 207. When the biller computing system116 generates an invoice at the biller entity, it stores the latter inthe invoice database 203 in association with a customer account entry inthe customer database 202. When a user sends to the biller computingsystem 116 a remittance detail file including payment records, theremittance detail file is stored in the payment record database 207 inassociation with a customer account entry in the customer database 202.The program element 204 processes the remittance detail file stored inthe payment record database 207 to generate account reconciliation datawhich is stored in the account reconciliation database 262 inassociation with a customer account entry in the customer database 202.

[0062] The account reconciliation data in account reconciliationdatabase 262 can then be used by the accounts receivable department atthe biller entity site to complete the reconciliation of the customeraccount. For example, the accounts receivable department receives fromthe payment network 152 data indicative of an amount received from aspecific customer. The accounts receivable department applies the amountreceived to the outstanding amount due for that customer on the basis ofthe account reconciliation data in account reconciliation database 262.

[0063] Program Element 204

[0064] The memory 200 also includes a program element 204 for operatingon the data 206 for generating account reconciliation data for acustomer entity. The generated account reconciliation data is stored indatabase 262.

[0065] A typical interaction will better illustrate the functioning ofthe system for providing account reconciliation data 100 and of programelement 204.

[0066] With reference to FIGS. 3 and 1 of the drawings, at step 400, auser associated to a customer entity transmits to the biller computingsystem 116 over network 106 a remittance detail file storing one or morepayment records including remittance detail data. In a firstnon-limiting example of implementation, the remittance detail fileincluding payment records is transmitted via e-mail to the billercomputing system 116. Preferably in such cases, appropriate securee-mail transmission procedures are used in order to insure suitableconfidentiality of the information being transmitted.

[0067] In a second non-limiting example of implementation, theremittance detail file including payment records is transmitted overnetwork 106 through a file upload feature in a designated website orover network 106 through any other suitable network protocols.

[0068] At step 402 the biller computing system 116 receives theremittance detail file and stores it in the database for storingcustomer payment records 207. Each payment record is associated to acorresponding request for payment in the invoice database 203.

[0069] The remittance detail data elements in the payment record arecompared to corresponding payment request parameters in the invoicedatabase 203 to derive a level of match between a payment record and agiven payment requests. The table below shows a non-limiting example ofthe mapping between the payment request parameters and the remittancedetail data. Corresponding payment Remittance detail data elementrequest parameter request identifier request identifier dollar amountpaid dollar amount due time data element time data element servicedescription data element service description data element productdescription data element product description data element

[0070] In a variant, each customer may transmit remittance detail filesin a customer specific format. The program element 204 maps theremittance detail files to a standard payment file format prior tocomparing the remittance detail data to corresponding payment requestparameters in the payment requests in the invoice database 203.

[0071] In a specific implementation, a plurality of levels of match areprovided. In a non-limiting example, the levels of match include acomplete match, a match with variance and an unreconciled item.

[0072] In a specific non-limiting implementation, the request identifierand the amount paid in the payment record are compared to the requestidentifier and the amount due in the payment request in order to derivea level of match.

[0073] The level of match between a payment record and a payment requestmay be indicative of a complete match. Rules may be used to determinewhen a level of match is an exact match. For example, a rule mayindicate that when the remittance detail data elements are an exactmatch to the payment request parameters, the level of match is acomplete match. Another rule may indicate that when certain remittancedetail data elements are an exact match to certain ones of the paymentrequest parameters, the level of match is a complete match. Another rulemay indicate that when an amount paid in a payment record and an amountdue in payment request differ by less than a threshold petty amount, butthat all other remittance detail data elements are a match, then thematch is indicative of a complete match.

[0074] The level match between a payment record and a payment requestmay be indicative of a match with variances. Rules may be used todetermine when a level of match is a match with variances. For example,a rule may indicate that when a certain remittance detail data elementis not a match to a corresponding payment request parameter and that allother remittance detail data elements are a match, then the level ofmatch is a match with variances. In another example, the rules mayindicate that when an amount paid in a payment record and an amount duein payment request differ but that all other remittance detail dataelements are a match, then the match is indicative of a match withvariances.

[0075] The level match between a payment record and a payment requestmay be indicative of an unreconciled item. Rules may be used todetermine when a level of match is indicative of an unreconciled item.For example, a rule may indicate that when a certain remittance detaildata element is not a match to a corresponding payment requestparameter, then the level of match is an unreconciled item.

[0076] The person skilled in the art will appreciate that the aboverules have been presented for the purpose of illustration only and thatmany other suitable rules may be used. Such rules will generally bedetermined on the basis of heuristics.

[0077] In order to associate a payment record to a corresponding requestfor payment, the remittance detail data elements in each payment recordare compared to corresponding payment request parameters in the paymentrequests in the invoice database 203 to locate a payment request with ahighest level of match. Many different search techniques may be used tolocate a highest level of match without detracting from the spirit ofthe invention. Such search techniques are well-known in the art and assuch will not be described further here.

[0078] Once a payment record is associated to a corresponding requestfor payment, at step 404, account reconciliation data is generated atleast in part on the basis of the remittance detail data and thecorresponding request for payment.

[0079] In a specific example, at step 404, a plurality of accountreconciliation events entries are generated, each account reconciliationevent including account reconciliation data associating a request forpayment identifier to an amount. Preferably, the account reconciliationdata also includes a data element indicative of the level of match. Inaccordance with a variant, each entry further includes a data elementindicative of the level of match between a given request for payment inthe invoice database and a payment record. The level of match may beindicative of either one of a complete match, a match with variances oran unreconciled item. In accordance with non-limiting implementation,when the level of match is indicative of a match with variances, thereconciliation event includes account reconciliation data indicative ofdifferences between the remittance detail data and the correspondingrequest for payment. Optionally, each entry further includes a paymentvehicle identifier. The payment vehicle identifier may be indicative ofa check number, a bank draft number, a wire transfer number or any othersuitable identifier for identifying a medium for transferring funds.

[0080] The table 6 below shows a specific non-limiting example of atable including entries associated to respective reconciliation events.In the table below, each row is associated to a respective accountreconciliation event. TABLE 6 Account Reconciliation Data for CustomerABC INC. Payment request Amount Level identifier due Amount paid ofmatch Differences S97468 5000$ 5000$ Complete S97478 2700$ 2600$ Matchwith Amount due ≠ amount variances paid S97374 1000$ 1000$ CompleteS97946 8000$ 8000$ Complete S94683 10000$ 2000$ Unreconciled Amounts andproduct description do not match. S94688 2200$ 2000$ Match with No matchfor product variances description Amount due ≠ amount paid S94693 1500$1500$ Complete

[0081] The account reconciliation data generated at step 404 is thenstored in database 262.

[0082] In accordance with a variant, the account reconciliation data istransmitted to a user at the customer site for display at the customercomputer unit. In a non-limiting implementation, when the level of matchfor a given account reconciliation event is indicative of a match withvariances, the user at the customer site is enabled to enter notes inassociation with the given account reconciliation event. The notes mayfor example describe the reason for differences between the remittancedetail data and the corresponding request for payment. The notesprovided by the user are then stored in the account reconciliationdatabase 262 in association with the given account reconciliation event.

[0083] The account reconciliation data in account reconciliationdatabase 262 can then be used by the accounts receivable system at themerchant/biller entity site 104 to complete the reconciliation of thecustomer account. For example, the accounts receivable system receivesfrom the payment network 152 data indicative of an amount received froma specific customer. The accounts receivable system associates theamount received at the bank to the outstanding amount due for thatcustomer on the basis of the account reconciliation data in accountreconciliation database 262.

[0084]FIG. 4 shows another very specific example of implementation of aprocess for generating account reconciliation data.

[0085] At step 700, a user associated to a customer entity generates aremittance detail file storing payment records including remittancedetail data. The remittance detail file may be generated using anysuitable software program commonly used in the art and the remittancedetail file may be in any suitable format.

[0086] At step 702, a user associated to the customer entity transmitsthe remittance detail file generated at step 702 to the biller computingsystem 116.

[0087] At step 704, the program element at the biller computing system116, performs some pre-processing on the remittance detail file. Suchpre-processing may include, without being limited to, verifying whetherthe remittance detail file is corrupt and checking for viruses.

[0088] If a problem is detected at the pre-processing step, a defaultprocess 705 is initiated.

[0089] If the pre-processing step is successful, at step 706, theremittance detail file is stored in the database for storing customerpayment records 207 (shown in FIG. 2).

[0090] At step 708, the remittance detail file is processed to determineif the remittance detail file corresponds to a new file format. The fileformat allows the program element 204 (shown in FIG. 2) to identify theappropriate mapping scheme for mapping remittance detail data in theremittance detail file to request parameters in the invoice database 203(shown in FIG. 2).

[0091] In a specific implementation, a plurality of known file formatsis provided to the biller computing system. If the remittance detailfile corresponds to a known file format, step 708 is answered in thenegative and the system proceeds to step 730. If the remittance detailfile does not correspond to a known file format, step 708 is answered inthe positive and the system proceeds to step 710.

[0092] At step 730, a request is generated to a mapping enginerequesting that the remittance detail file be mapped to a standard fileformat. At step 732, the remittance detail file is mapped, on the basisof the file format associated to the remittance detail file to generatea payment file having a format indicative of a standard payment fileformat.

[0093] At step 734, a test is effected to determine whether the mappingeffected at step 732 was successful. In the negative, the systemproceeds to step 712 where the remittance detail file is brought to theattention of an analyst associated with the biller entity so that thelatter can determine where the problem occurred. If the test at step 734is successful, the system proceeds to step 736.

[0094] At step 736, the remittance detail file mapped in the standardpayment file format is processed on the basis of the invoice database203 (shown in FIG. 2) to associate the payment records to correspondingrequests for payment in the invoice database. The association iseffected on the basis of levels of match between the payment records andthe requests for payment. Following this, account reconciliation data isgenerated.

[0095] At step 738, a test is effected to determine whether thegeneration of account reconciliation data effected at step 736 wassuccessful. In the negative, the system proceeds to step 712 where theremittance detail file is brought to the attention of an analystassociated with the biller entity. If the test at step 738 isaffirmative, the account reconciliation data is stored in database 262and the system proceeds to step 740.

[0096] At step 740, a message is sent to the customer computing unit 112for causing the latter to display to the user a transaction confirmationmessage. The transaction confirmation message may be transmitted to theuser via e-mail, over a network through a web-based application or anyother suitable communication fashion. Various types of informationderived from the reconciliation data may be present on the transactionconfirmation message. In a first example of implementation, thetransaction confirmation message includes a message indicating that theremittance detail file has been processed. In a second example ofimplementation, the transaction confirmation message includes a messagethat the remittance detail file has been processed and an indication ofthe number of items having a given level of match found. In yet a thirdexample of implementation, the transaction confirmation message includesdata indicative of the reconciliation data generated at step 736.Optionally, the transaction confirmation message prompts a user at thecustomer computing unit 112 to enter comments via a user interface (suchas a keyboard, mouse, pointer, voice recognition or touch sensitivescreen amongst others) associated to the account reconciliation datadisplayed. In particular, when the level of match for a given accountreconciliation event is indicative of a match with variances, the userat the customer site is enabled to enter notes in association with thegiven account reconciliation event. The notes may for example describethe reason for differences between the remittance detail data and thecorresponding request for payment. The notes provided by the user aretransmitted back to the biller computing system and stored in theaccount reconciliation database 262 in association with the givenaccount reconciliation event. Advantageously these notes may assist theaccounts receivable department at the biller computing unit to ascertainwhy certain reconciliation events are associated to a level of matchindicative of a match with variances.

[0097] Other types of information may be present on the transactionconfirmation screen without detraction from the spirit of the invention.FIG. 6 of the drawings shows a specific non-limiting example ofimplementation of a transaction confirmation message displayed in theform of a web-based application.

[0098] As depicted, the page 1000 includes a first information portion1004 including details associated with the remittance detail filetransmitted by the customer entity. In this example, these detailsinclude the date and time 1006 at which the remittance detail file wastransmitted to (or alternatively received by) the merchant entity; theformat and name of the remittance detail file 1008; the user 1010associated with the customer entity and who transmitted the remittancedetail file; an amount paid 1012 associated to a payment vehicleidentifier; a scheduled payment date 1014; a payment status indicator1016; and a payment vehicle identifier 1018. Additional data may beadded and certain data may be omitted without detracting from the spiritof the invention.

[0099] The page 1000 includes a second information portion 1002including reconciliation data associated of the remittance detail filetransmitted by the customer entity. In this second information portion,details regarding the number of reconciliation events associated to eachlevel match is shown. Optionally, the user is enabled to view thereconciliation data in greater detail such as to view eachreconciliation event individually.

[0100] At step 742, the account reconciliation data is stored in theaccount reconciliation database 262 for future access by the accountsreceivable process. At this stage, the account reconciliation data inaccount reconciliation database 262 can be used by the accountsreceivable department at the biller entity site to complete thereconciliation of the customer account. For example, the accountsreceivable system receives from the payment network 152 data indicativeof an amount received from a specific customer. The accounts receivabledepartment applies the amount received at the bank to the outstandingamount due for that customer on the basis of the account reconciliationdata in account reconciliation database 262. This process may be donemanually or automatically using suitable computing systems withoutdetracting from the spirit of the invention.

[0101] At step 708, if the remittance detail file uploaded by the userdoes not correspond to a known file format, step 708 is answered in thepositive and the system proceeds to step 710.

[0102] At step 710, a new customer file format is added to the list ofknown file formats. The system proceeds to step 712 where the remittancedetail file is brought to the attention of an analyst associated withthe biller entity.

[0103] At step 714, the remittance detail file is marked as being underanalysis.

[0104] At step 716, a message is sent to the customer computing unit 112for causing the latter to display to the user a message indicating thatthe remittance detail file is under analysis. The message may betransmitted to the user via e-mail, over a network through a web-basedapplication or any other suitable communication fashion.

[0105] At steps 718 and 720, an analyst associated with the billerentity looks at the remittance detail file to determine whether amapping scheme between the format of the remittance detail file and thestandard payment file format already exists. If no mapping schemeexists, step 722 is answered in the negative and the system proceeds tostep 724 where a new mapping scheme is created for the new file formatto allow mapping the new file format into the standard payment fileformat.

[0106] If a mapping scheme between the format of the remittance detailfile and the standard payment file format already exists, step 722 isanswered in the affirmative and the system proceeds to step 726.

[0107] At step 726, the list of known file formats is updated to reflectthe mapping between format of the remittance detail file and thestandard payment file format. Following this, at step 728, suitabletesting step for the format of the remittance detail file are effected.The remittance detail file may then resume processing at step 730.

[0108] Specific Example of Implementation

[0109] In a non-limiting example of implementation, in order to viewinvoices and upload remittance detail data, the users associated withthe customer entity log on to a secure web-site using login names andassociated passwords. The account information is displayed on agraphical user interface on the customer's computer terminal. In atypical interaction, users associated to the customer entity access adesignated website through a network link by providing a network addressin order to view invoices and other account information. The users logon to the secure website by providing login information including acustomer identifier, a login name and a password. With reference to FIG.2, the biller computing system receives the login information andprocesses it with respect to the customer database 202. Morespecifically, the processor 208 accesses the customer database 202 tolocate the entry corresponding to the customer identifier. If nocorresponding entry is found, an error message is returned to thecustomer entity. If a corresponding entry is found, the processor 208attempts to locate a record corresponding to the login name provided. Ifno corresponding record is found, an error message is returned to theuser. If a corresponding record is found, the password in the record iscompared to the password provided in the login information. If a matchis not found, an error message is returned to the user. If a match isfound, the user is successfully identified. Once a user is successfullyidentified, the account information in the invoice database 203corresponding to the customer identifier is made available to the userand the user is enabled to transmit remittance detail files includingremittance detail data to the biller computing system over network 106(shown in FIG. 1).

[0110] In a non-limiting example of implementation, the program element204 implements a payment module to aid the user in the completion of theonline payment process including the transmission of files includingremittance detail data. The program element 204 includes a first programelement component for causing a customer computing unit to display agraphical user interface for the payment module. In a specific exampleof implementation, the payment module is configured to providestep-by-step instructions.

[0111]FIG. 5 of the drawings shows a specific example of implementationof a user interface suitable for use in connection with a paymentmodule. As shown, the user interface 300 includes a form includingvarious fields prompting the user to provide remittance detail data.

[0112] The payment instructions may include providing the biller with acredit card number, with an authorization to debit a bank account, wiretransfer information, direct deposit information or a check numberamongst others. In the example shown, the interface 300 provides fieldsfor entering the payment date 302, payment amount 304, currency 306,payment vehicle 308 and payment vehicle identifier 310. The paymentmodule further provides a facilitator 314 allowing the user to uploadremittance detail files including payment details. The facilitator 314may be in the form of an editable text field, a pull-down menu or a linkto the user's directory structure. Optionally, the interface provides afield 312 for specifying the format of the remittance detail file. Oncethe user has provided the necessary information, the information istransmitted to the merchant computing system. The interface 300 includesall the necessary routing information to transmit the informationentered by the user in the various fields as well as the remittancedetail file to the biller computing system. In this specific example,the user transmits the information by pressing an “UPLOAD” button 320 onthe user interface 300.

[0113] The remittance detail files including remittance detail data oncereceived by the biller computing system is then processed according tothe processes described above.

[0114] Although the present invention has been described in considerabledetail with reference to certain preferred embodiments thereof,variations and refinements are possible without departing from thespirit of the invention. Therefore, only the appended claims and theirequivalents should limit the scope of the invention.

1) A method for providing information regarding a customer account, thecustomer account including a plurality of entries, each entry beingindicative of a request for payment, said method comprising: a)receiving over a network from a user associated to the customer accounta payment record including remittance detail data; b) generating accountreconciliation data at least in part on the basis of the remittancedetail data and the entries in the customer account; c) transmittingover a network a signal, the signal being suitable for causinginformation derived from the account reconciliation data to be displayedon a display screen. 2) A method as defined in claim 1, wherein theaccount reconciliation data includes: a) a request identifier associatedto the corresponding request for payment; b) an amount data element. 3)A method as described in claim 1, further comprising: a) associating thepayment record to a corresponding request for payment in the customeraccount at least in part on the basis of a level of match between theremittance detail data and the corresponding request for payment in thecustomer account; b) generating account reconciliation data at least inpart on the basis of the remittance detail data and the correspondingrequest for payment. 4) A method as defined in claim 3, wherein theaccount reconciliation data includes: a) a request identifier associatedto the corresponding request for payment; b) an amount data element. 5)A method as defined in claim 3, wherein the level of match is indicativeof either one of a complete match, a match with variances or anunreconciled item. 6) A method as defined in claim 5, wherein theaccount reconciliation data includes data indicative of differencesbetween the remittance detail data and the corresponding request forpayment when the level of match is indicative of a match with variances.7) A method as defined in claim 1, said method comprising enabling auser to provide explanation data in association with the accountreconciliation data. 8) A method as defined in claim 1, wherein thenetwork is the Internet. 9) A method as defined in claim 3, wherein eachentry in the customer account includes a plurality of payment requestparameters, said method comprising comparing the detail data to thepayment request parameters to derive a level of match between the givenpayment record and an entry in the customer account. 10) A method asdefined in claim 9, wherein the remittance detail data includes at leastone remittance detail data element selected from the set consisting of adollar amount paid, a payment request identifier, a time data element, aservice description data element and a product description data element.11) A method as defined in claim 10, wherein the plurality of paymentrequest parameters includes at least one request parameter selected fromthe set consisting of a dollar amount due, a payment request identifier,a time data element, a service description data element and a productdescription data element. 12) A method as defined in claim 9, wherein:a) an entry in the customer account includes a request parameterindicative of a dollar amount due; and b) the payment record includes aremittance detail data element indicative of a dollar amount paid; saidmethod comprising comparing the remittance detail data elementindicative of a dollar amount paid with a payment request parameterindicative of an amount due in a given entry in the customer amount toderive a level of match. 13) A method as defined in claim 12, wherein alevel of match indicative of a complete match is derived when the dataelement indicative of the amount due differs from the data elementindicative of the dollar amount paid by less than a threshold pettyamount. 14) A method for providing information regarding a customeraccount, the customer account including a plurality of entries, eachentry being indicative of a request for payment, said method comprising:a) enabling a user at a computer terminal to transmit data indicative ofa payment record including remittance detail data associated to thecustomer account; b) causing information data to be displayed at thecomputer terminal, the information data being indicative of accountreconciliation information derived at least in part on the basis of theremittance detail data and the entries in the customer account. 15) Amethod as defined in claim 14, wherein the account reconciliation dataincludes: a) a request identifier associated to the correspondingrequest for payment; b) an amount data element. 16) A method as definedin claim 15, wherein the account reconciliation data further includes adata element indicative of a level of match between the remittancedetail data and the entries in the customer account. 17) A method asdefined in claim 16, wherein the level of match is indicative of eitherone of a complete match, a match with variances or an unreconciled item.18) A method as defined in claim 17, wherein the account reconciliationdata includes data indicative of differences between the remittancedetail data and the corresponding request for payment when the level ofmatch is indicative of a match with variances. 19) A method as definedin claim 14, said method comprising enabling a user at the computerterminal to provide explanation data in association with the accountreconciliation data. 20) A computer-readable medium comprisingcomputer-executable instructions for: a) storing a customer account at abiller entity, the customer account including a plurality of entries,each entry being indicative of a request for payment, the request forpayment being issued by the biller entity to a customer entity; b)receiving over a network a payment record including remittance detaildata; c) generating account reconciliation data at least in part on thebasis of the remittance detail data and the entries in the customeraccount; d) transmitting over a network a signal, the signal beingsuitable for causing information derived from the account reconciliationdata to be displayed on a display screen. 21) A computer readablestorage medium as defined in claim 20, wherein the accountreconciliation data includes: a) a request identifier associated to thecorresponding request for payment; b) an amount data element. 22) Acomputer readable storage medium as described in claim 20, furthercomprising computer-executable instructions for: a) associating thepayment record to a corresponding request for payment in the customeraccount at least in part on the basis of a level of match between theremittance detail data and the corresponding request for payment in thecustomer account; b) generating account reconciliation data at least inpart on the basis of the remittance detail data and the correspondingrequest for payment. 23) A computer readable storage medium as definedin claim 22, wherein the account reconciliation data includes: a) arequest identifier associated to the corresponding request for payment;b) an amount data element. 24) A computer readable storage medium asdefined in claim 22, wherein the level of match is indicative of eitherone of a complete match, a match with variances or an unreconciled item.25) A computer readable storage medium as defined in claim 24, whereinthe account reconciliation data includes data indicative of differencesbetween the remittance detail data and the corresponding request forpayment when the level of match is indicative of a match with variances.26) A computer readable storage medium as defined in claim 20, furthercomprising computer-executable instructions for enabling a user toprovide explanation data in association with the account reconciliationdata. 27) A computer readable storage medium as defined in claim 20,wherein the network is the Internet. 28) A computer readable storagemedium as defined in claim 22, wherein each entry in the customeraccount includes a plurality of payment request parameters, saidcomputer readable storage medium further comprising computer-executableinstructions for comparing the detail data to the payment requestparameters to derive a level of match between the given payment recordand an entry in the customer account. 29) A computer readable storagemedium as defined in claim 28, wherein the remittance detail dataincludes remittance detail data elements selected from the setconsisting of a dollar amount paid, a payment request identifier, a timedata element, a service description data element and a productdescription data element. 30) A computer readable storage medium asdefined in claim 29, wherein the plurality of payment request parametersincludes request parameters selected from the set consisting of a dollaramount due, a payment request identifier, a time data element, a servicedescription data element and a product description data element. 31) Acomputer readable storage medium as defined in claim 28, wherein: a) anentry in the customer account includes a request parameter indicative ofa dollar amount due; and b) the payment record includes a remittancedetail data element indicative of a dollar amount paid; said computerreadable storage medium further comprising computer-executableinstructions for comparing the remittance detail data element indicativeof a dollar amount paid with a payment request parameter indicative ofan amount due in a given entry in the customer amount to derive a levelof match. 32) A computer readable storage medium as defined in claim 31,wherein a level of match indicative of a complete match is derived whenthe data element indicative of the amount due differs from the dataelement indicative of the dollar amount paid by less than a thresholdpetty amount. 33) A computer-readable medium comprisingcomputer-executable instructions for: a) enabling a user at a computerterminal to transmit data indicative of a payment record includingremittance detail data associated to the customer account; b) causinginformation data to be displayed at the computer terminal, theinformation data being indicative of account reconciliation informationderived at least in part on the basis of the remittance detail data andthe entries in the customer account. 34) A computer readable storagemedium as defined in claim 33, wherein the account reconciliation dataincludes: a) a request identifier associated to the correspondingrequest for payment; b) an amount data element. 35) A computer readablestorage medium as defined in claim 34, wherein the accountreconciliation data further includes a data element indicative of alevel of match between the remittance detail data and the entries in thecustomer account. 36) A computer readable storage medium as defined inclaim 35, wherein the level of match is indicative of either one of acomplete match, a match with variances or an unreconciled item. 37) Acomputer readable storage medium as defined in claim 36, wherein theaccount reconciliation data includes data indicative of differencesbetween the remittance detail data and the corresponding request forpayment when the level of match is indicative of a match with variances.38) A computer readable storage medium as defined in claim 33, furthercomprising computer-executable instructions for enabling a user at thecomputer terminal to provide explanation data in association with theaccount reconciliation data. 39) A computer readable storage mediumstoring a program element for execution by a CPU for providinginformation regarding a customer account, the customer account includinga plurality of entries, each entry being indicative of a request forpayment, the request for payment being issued by a biller entity to acustomer entity, said program element comprising: a) a first programelement component for causing a computer to deliver first information toa user, the first information prompting the user to provide a paymentrecord including remittance detail data; b) a second program elementcomponent responsive to the payment record for generating accountreconciliation data at least in part on the basis of the remittancedetail data and the entries in the customer account; c) a third programelement for transmitting over a network a signal, the signal beingsuitable for causing information derived from the account reconciliationdata to be displayed on a display screen. 40) A computer readablestorage medium as defined in claim 39, wherein the accountreconciliation data includes: a) a request identifier associated to thecorresponding request for payment; b) an amount data element. 41) Acomputer readable storage medium as described in claim 39, wherein saidsecond program element is further adapted for: a) associating thepayment record to a corresponding request for payment in the customeraccount at least in part on the basis of a level of match between theremittance detail data and the corresponding request for payment in thecustomer account; b) generating account reconciliation data at least inpart on the basis of the remittance detail data and the correspondingrequest for payment. 42) A computer readable storage medium as definedin claim 41, wherein the account reconciliation data includes: a) arequest identifier associated to the corresponding request for payment;b) an amount data element. 43) A computer readable storage medium asdefined in claim 41, wherein the level of match is indicative of eitherone of a complete match, a match with variances or an unreconciled item.44) A computer readable storage medium as defined in claim 43, whereinthe account reconciliation data includes data indicative of differencesbetween the remittance detail data and the corresponding request forpayment when the level of match is indicative of a match with variances.45) A computer readable storage medium as defined in claim 39, furthercomprising a fourth program element component for enabling a user toprovide explanation data in association with the account reconciliationdata. 46) A computer readable storage medium as defined in claim 39,wherein the network is the Internet. 47) A computer readable storagemedium as defined in claim 41, wherein each entry in the customeraccount includes a plurality of payment request parameters, said secondelement component is adapted for comparing the detail data to thepayment request parameters to derive a level of match between the givenpayment record and an entry in the customer account. 48) A computerreadable storage medium as defined in claim 47, wherein the remittancedetail data includes remittance detail data elements selected from theset consisting of a dollar amount paid, a payment request identifier, atime data element, a service description data element and a productdescription data element. 49) A computer readable storage medium asdefined in claim 48, wherein the plurality of payment request parametersincludes request parameters selected from the set consisting of a dollaramount due, a payment request identifier, a time data element, a servicedescription data element and a product description data element. 50) Acomputer readable storage medium as defined in claim 47, wherein: a) anentry in the customer account includes a request parameter indicative ofa dollar amount due; and b) the payment record includes a remittancedetail data element indicative of a dollar amount paid; wherein saidsecond program element component is operative for comparing theremittance detail data element indicative of a dollar amount paid with apayment request parameter indicative of an amount due in a given entryin the customer amount to derive a level of match. 51) A computerreadable storage medium as defined in claim 50, wherein a level of matchindicative of a complete match is derived when the data elementindicative of the amount due differs from the data element indicative ofthe dollar amount paid by less than a threshold petty amount. 52) Acomputer readable storage medium as defined in claim 39, wherein thedelivering of the first information to the user is done by displayinginformation on a screen. 53) A computer readable storage medium asdefined in claim 52, wherein the user provides the payment recordthrough an input device selected in the group consisting of keyboard,pointing device, touch sensitive surface, speech recognition unit and afile. 54) A computer readable storage medium as defined in claim 39,wherein the CPU resides on a server machine and the computer is a clientmachine in a network arrangement with the server machine. 55) A computerreadable storage medium as defined in claim 39, wherein the CPU residesin the computer. 56) A computer readable storage medium as defined inclaim 55, wherein the first program element component generates controlmessages to the client machine to cause the client machine to displayinformation to the user. 57) A computer readable storage medium asdefined in claim 56, wherein the control messages are HTTP messages andthe client machine displays information to the user through a webbrowser. 58) A server system for providing information regarding acustomer account, the customer account including a plurality of entries,each entry being indicative of a request for payment, the request forpayment being issued by a biller entity to a customer entity, saidserver system storing a program element for execution by a CPU, saidprogram element comprising: a) a first program element component forcausing a client system connected to the server via a network to displayfirst information to a user, the first information prompting the user toprovide a payment record including remittance detail data; b) a secondprogram element component responsive to the payment record forgenerating account reconciliation data at least in part on the basis ofthe remittance detail data and the entries in the customer account; c) athird program element component for transmitting to the client systemover a network a signal, the signal being suitable for causinginformation derived from the account reconciliation data to be displayedon a display screen at the client system. 59) A system as defined inclaim 58, wherein the account reconciliation data includes: a) a requestidentifier associated to the corresponding request for payment; b) anamount data element. 60) A system as described in claim 58, wherein saidsecond program element is further adapted for: a) associating thepayment record to a corresponding request for payment in the customeraccount at least in part on the basis of a level of match between theremittance detail data and the corresponding request for payment in thecustomer account; b) generating account reconciliation data at least inpart on the basis of the remittance detail data and the correspondingrequest for payment. 61) A computer readable storage medium as definedin claim 60, wherein the account reconciliation data includes: a) arequest identifier associated to the corresponding request for payment;b) an amount data element. 62) A system as defined in claim 60, whereinthe level of match is indicative of either one of a complete match, amatch with variances or an unreconciled item. 63) A system as defined inclaim 62, wherein the account reconciliation data includes dataindicative of differences between the remittance detail data and thecorresponding request for payment when the level of match is indicativeof a match with variances. 64) A system as defined in claim 60, whereinsaid program element comprises a fourth program element component forenabling a user to provide explanation data in association with theaccount reconciliation data. 65) A client-server system for providinginformation regarding a customer account, the customer account includinga plurality of entries, each entry being indicative of a request forpayment, the request for payment being issued by a biller entity to acustomer entity, said client-server system comprising: a) a clientsystem; b) a server system, said client system and said server systemoperative to exchange messages over a data network; c) a first programelement component executed on said server system for sending messages tosaid client system for causing said client system to display firstinformation to a user, the first information prompting the user toprovide a payment record including remittance detail data; d) saidclient system being operative to send messages to said server tocommunicate to said server the payment record including remittancedetail data; e) a second program element component executed on saidserver responsive to the payment record for generating accountreconciliation data at least in part on the basis of the remittancedetail data and the entries in the customer account; f) a third programelement component executed on said server for a second program elementcomponent for transmitting to the client system over a network a signal,the signal being suitable for causing information derived from theaccount reconciliation data to be displayed on a display screen at theclient system. 66) A client-server system as defined in claim 65,wherein said client system displays said first information through abrowser.